shared: attempt a faster date <-> rate die algorithm #449
Conversation
|
cc @benjoffe - I hope you don't mind the ping. :-) |
This comes from: https://www.benjoffe.com/fast-date-64 More specifically, the code is here: https://github.com/benjoffe/fast-date-benchmarks/blob/7fcf82b07d340ddbec866e15cfe333485439ab7f/algorithms/benjoffe_fast64.hpp But the benchmarks don't show an improvement: ``` $ critcmp base x01 group base x01 ----- ---- --- civil_datetime/to_timestamp_static/bundled/jiff 1.00 10.5±0.09ns ? ?/sec 1.03 10.9±0.07ns ? ?/sec civil_datetime/to_timestamp_static/zoneinfo/jiff 1.00 10.4±0.09ns ? ?/sec 1.03 10.8±0.07ns ? ?/sec timestamp/to_civil_datetime_offset_conversion/jiff 1.00 4.4±0.05ns ? ?/sec 1.03 4.6±0.03ns ? ?/sec ``` I ran the benchmarks like this: ``` cd bench ``` Before the change: ``` cargo bench --'(civil_datetime/to_timestamp_static|timestamp/to_civil_datetime_offset_conversion).*jiff' --save-baseline base ``` And then after the change: ``` cargo bench --'(civil_datetime/to_timestamp_static|timestamp/to_civil_datetime_offset_conversion).*jiff' --save-baseline x01 ``` Then I used [`critcmp`] to compare them: ``` critcmp base x01 ``` It's very possible I didn't port it correctly. I haven't scrutinized the codegen. It's also possible that there is an improvement, but that it's hard to write a benchmark using Jiff APIs to observe it. (Note that I left out the ARM-specific bits. I'm testing this on x86-64. I wanted to test there first before digging into the platform specific optimizations.) [`critcmp`]: https://github.com/BurntSushi/critcmp
|
Hi, thanks for trying out the algorithm! I'm very keen to help out, it'll be great to see this used successfully in the wild. I have to first note, I have never programmed in Rust before, however it's been high on my list to try out, and this is the perfect push for me. At first glance, it looks right, and if it passes tests I assume it's been ported correctly.
And finally, perhaps you are testing this on a x64 Mac? There is a note at the end of my blog post that x64 Mac does not surface the same speed gains in the benchmarks (it's still faster, but by less), which I presume is due to the power management features of the OS or chip activating when 64 bit math is run in a tight loop. If it turns out that Rust is unable to compile the 128-bit arithmetic to direct register access, then it might be that the 32-bit friendly alternative is going to end up faster in this language*. It would be unfortunate to have to fallback to that, as it only achieves 3/4 of the speed gains over Neri-Schneider, but could be an interesting thing to test if you run out of ideas. Finally, I note that the inverse function can be 1-cycle faster if you only need to support 32-bit inputs but are only targeting speed on 64-bit machines - by using 64-bit internal arithmetic and then changing I'll be able to have a deeper dive later, hopefully in the next week or two. |
|
I don't have hands on a keyboard, so excuse the short reply. But thank you for responding! rustc uses llvm, so I would be very surprised if rudimentary constant folding or simple branch avoidance wasn't happening. The 128-bit handling I'm less sure about though. For your benchmarks, did you use gcc or clang? Either way, when I get hands on a keyboard, I'll post the codegen here (and show you how I got it). The previous Neri-Schneider implementation used similar techniques, and I had looked at its codegen and at least verified there was no branching or div instructions. My benchmarks above were on a quiet Linux desktop with the CPU governor set to performance mode. Thanks again for taking a look! |
|
Also, Jiff only requires 32 bit integers to represent rata die. Namely, Jiff only supports years -9999 to 9999. |
|
The benchmark table at the bottom of the blog post specifies the compilers used. For Windows it was MSVC 19.44, and on Apple M4 Pro: Apple clang 17.0.0. Since the date range is restricted to just +-9999 - you don't need to hoist to 64-bit to safely use the more compact, and faster code in the inverse: |
|
Upon further investigation, perhaps the issue is the usage of (A as u128) * (B as u128). |
|
These are the results on my Macbook Pro M4 Pro, following your steps with no code changes: |
|
Hmmm, if I do this: Then that |
|
To get the codegen for the YMD -> rate die conversion, you'll need First you'll need to mark the function as unlineable: And then run: Which will print the assembly to stdout: .section .text.jiff::shared::util::itime::IDate::to_epoch_day,"ax",@progbits
.globl jiff::shared::util::itime::IDate::to_epoch_day
.p2align 4
.type jiff::shared::util::itime::IDate::to_epoch_day,@function
jiff::shared::util::itime::IDate::to_epoch_day:
.cfi_startproc
movsx eax, word ptr [rdi]
movsx ecx, byte ptr [rdi + 2]
cmp ecx, 3
sbb eax, 0
imul edx, ecx, 979
lea esi, [rdx - 2919]
add edx, 8829
cmp ecx, 3
cmovae edx, esi
add eax, 5880000
imul rcx, rax, 1374389535
mov rsi, rcx
shr rsi, 37
imul r8d, eax, 365
shr eax, 2
shr rcx, 39
lea r9d, [rdx + 31]
test edx, edx
cmovns r9d, edx
movsx edx, byte ptr [rdi + 3]
sar r9d, 5
add eax, edx
add eax, r8d
sub eax, esi
add eax, ecx
add eax, r9d
add eax, 2146621927
retYou can also ask for llvm IR: Which gives: And now using the above approach for the rata die -> YMD conversion (don't forget to mark Which gives the Assembly: And adding the |
|
If I set the environment variable Benchmarking with And I get: So hmmm, no dice. I'll pause here for now. I haven't tried the 32-bit algorithms yet. How does the codegen I've shared look to you? I figure you might be able to spot issues there more easily than I can. |
|
Thanks for showing how to view the assembly, that helps a lot. It seems the 64x64 -> 128 multiplications are working fine - but there is a left-shift by 24 which is out of nowhere, and indicates that it might be adjusting the math somewhere to no longer be aligned perfectly into the 64-bit registers. I'll dig deeper in the next week or two and see what can be changed to keep it closer to the intended output. |
This comes from:
https://www.benjoffe.com/fast-date-64
More specifically, the code is here:
https://github.com/benjoffe/fast-date-benchmarks/blob/7fcf82b07d340ddbec866e15cfe333485439ab7f/algorithms/benjoffe_fast64.hpp
But the benchmarks don't show an improvement:
I ran the benchmarks like this:
Before the change:
And then after the change:
Then I used
critcmpto compare them:It's very possible I didn't port it correctly. I haven't scrutinized the
codegen. It's also possible that there is an improvement, but that it's
hard to write a benchmark using Jiff APIs to observe it.
(Note that I left out the ARM-specific bits. I'm testing this on x86-64.
I wanted to test there first before digging into the platform specific
optimizations.)